1. Field of the Invention
This patent application is a continuation of U.S. patent application Ser. No. 10/047,011, filed on Jan. 16, 2002, which was a continuation-in-part of U.S. application Ser. No. 09/497,606, filed on Feb. 3, 2000, now issued as U.S. Pat. No. 6,550,058. This invention relates to technologies and methods for debugging runtime exceptions when developing or testing software, and especially to debugging and diagnosing failures related to Java and embedded Java Virtual Machines.
2. Description of the Related Art
The Java programming language and Java Virtual Machine (JVM) execution environment are well known in the art. Many programmers and designers are skilled at developing application programs in Java to be run under a JVM.
An “exception”, according to the Java Virtual Machine Specification, is defined as an event which occurs when a Java program violates the semantic constraints of the Java language. For example, a program may attempt to index outside the bounds of a data array. In general, an exception may be “thrown” for one of three reasons:                (1) an abnormal execution condition is synchronously detected by a Java Virtual Machine;        (2) an operation is performed that violates the normal semantics of the Java language, such as indexing outside the bounds of an array; or        (3) an error occurs when loading or linking part of a Java program.        
When an exception is thrown, the JVM performs a non-local transfer of control from the point where the exception occurred to an exception handling point, which is specified by the designer of the violating program. Therefore, in Java parlance, the exception is “thrown” from the point were the error occurs, and “caught” at the point to which control is transferred. If the exception is caught at a point outside the violating method, it is referred to as having completed abruptly.
Using “throw statements”, Java programs may also throw exceptions explicitly, which provides an alternative to the traditional method of returning error values, such as the integer value “−1”.
In order to throw an exception, a JVM abruptly completes, one-by-one, all expressions, statements, method and constructor invocations, static initializers, and field initialization expressions that are running in the current thread until a handler is found that indicates that it handles the thrown exception (e.g. by naming the class of the exception or a superclass of the class of the exception). If no exception handler is found, a default method, “uncaught-Exception”, is invoked for the thread group that is the parent of the current thread.
The Java class “RuntimeException” is a subclass of class “Exception”, subclasses of which are unchecked exception classes. The unchecked runtime exceptions defined by package “java.lang” are given in Table 1.
TABLE 1Java Runtime ExceptionsException NameExample or DescriptionArithmetic Exceptionan integer division or remainderoperation with a zero divisorArray Store Exceptionstoring a value whose class is notassignment compatible with thecomponent type of the arrayClass Cast Exceptioncasting a reference to an object to aninappropriate typeIllegal Monitor State Exceptionwaiting on an object that it has not beenlockedIndex Out Of Bounds Exceptionan index or a subrange specified out ofrangeNegative Array Size Exceptioncreating an array with a negative lengthNull Pointer Exceptionusing a null reference in a case wherean object reference is requiredSecurity Exceptionsecurity violation
While debugging Java runtime exceptions (e.g. NULL pointer), it is difficult to locate the origin of the exceptions because the call chain is generated from the nearest method which catches the exception. Many of the methods which were executed in between are skipped by the dump stack methods, which obfuscates the call-path and the method which caused the exception.
When using embedded Java Virtual Machines (JVM), the ability of an engineer or software tester to be able to find the originator of an uncaught exception is especially important as the exception can possibly bring the entire JVM down.
Therefore there is a need in the art for a system and method which aids a software designer in determining the originator of an uncaught exception so that the program error may be diagnosed and corrected. Further, there is a need in the art for this new system and method to be readily useful for popular programming languages and environments such as Java and JVM's.